%!TEX root = report.tex

\section{Insights and Experiences}
\label{sec:exp}

We discuss our experiences throughout the course of the project and insights into the process of Model Driven Development in this section. 
Our project was primarily comprised of three tasks: Modelling, Transformation and Framework Development. 
We discuss our experiences with each task in the subsections below.

\subsection{Meta-Modelling}
In this task, we attempted to design and implement a metamodel for our textual DSL using Xtext. 
We gained valuable insights into the modelling process as well as experience of using Xtext while working on this task. 
Some of the important insights we gained include:

\begin{enumerate}
\item \textbf{Documentation and Tutorials:} It's great to work with a tool that has good documentation developer support. We found Xtext to be a very well maintained project in this regard. The website is kept up to date and there is documentation available up to Xtext 2.1. The version we used was Xtext 2.2 (and Xtext 2.3 has just been released) but the documenation available was adequate for our needs. There are also a couple of really helpful tutorials that guide the user through the process of setting up an Xtext project and developing a simple metamodel.
\item \textbf{Active Development Cycle and Forum:} Xtext is actively maintained by Itemis~\cite{www:itemis} and new releases occur frequently. There is also a vibrant community of users. The Eclipse.org Textual Modelling Framework forum~\cite{www:tmf} has many experienced Xtext developers available to answer queries if one gets stuck. There is also a large repository of problems and solutions that other users have faced.
\item \textbf{Eclipse Modelling Framework:} As Xtext is based on EMF, it is really helpful to have some understanding of EMF beforehand. We did not have any prior knowledge of EMF, therefore it was sometimes difficult to follow along with the tutorials and discussions on the forums as most of the users were experienced in modelling techniques and the EMF ecosystem. One benefit of having EMF as the underlying technology is that the models generated using Xtext can be integrated with other EMF based tools easily.
\item \textbf{Good Abstractions:} Even though Xtext is based on EMF, the end-user does not need to have a great deal of knowledge about EMF to get started with Xtext. The developers of Xtext have done a great job of developing a solid abstraction layer on top of EMF. Users don't have to directly interact with EMF at any level to develop a working DSL.
\item \textbf{Eclipse Integration:} Xtext integrates seamlessly with Eclipse. There are no loose odds and ends. Xtext provides the end-user with a meta-modelling tool that utilizes the power of Eclipse by integrating syntax highlighting, code completion, validation and outline view in the created DSL editor. If Xtext existed as a project separate from Eclipse, it would not be possible to create such a strong environment for working with DSLs.

\end{enumerate}

\textbf{Problems Faced: } We also faced some difficult problems while developing the metamodel. Some of these problems were:

\begin{enumerate}
\item \textbf{EBNF Grammar:} As Xtext requires that the metamodel be specified in the form of an EBNF grammar, we had to revise some concepts previously learned in theory of computation and compiler construction. It was helpful to have that background. It would be difficult for someone without a Computer Science background to grasp these concepts quickly.
\item \textbf{Left Factoring and Removing Left Recursion:} Xtext requires that the defined grammar be a LL(1) grammar, therefore the grammar must be left factored and left recursion must be removed. Because of this, we had to spend time revising how to left factor a grammar and remove left recursion.
\item \textbf{Inexplicable Crashes:} Whenever we ran a new Eclipse instance with the integrated plugin for our DSL, it would inexplicably crash as soon as we wrote a bit of code, giving a Java Out of Memory Exception. We were unable to solve this problem for two or three days. While searching through the forums, we found that this problem occurs due to a problem in the outline view. Therefore, we closed the outline view and the editor seemed to work fine.

Later, we modified the outline view to only display the mode names rather than the entire syntax tree. This seemed to solve the problem of inexplicable crashes.
\item \textbf{Large Memory and CPU Requirement:} If we ran the Eclipse instance with our plugin, it would crash after we created a few modes in our DSL. When we investigated this problem further, we found that the problem was that the JVM needed to be allocated more memory. Therefore, we increased the amount of memory allocated to the Eclipse instance, the maximum memory size, and the amount of memory for storing permanent objects. The DSL editor seemed to be stable after that.

Also, when we monitored the CPU utilization while using our DSL editor, one of the cores of the CPU was constantly fully utilized by the Eclipse instance.
\end{enumerate}

\subsection{Transformation}
This task involved implementing a code generator which transformed our textual models into Java code that could be integrated into the bicycle computer.
We learned many things in this task. Some of the insights we gained are given below:

\begin{enumerate}
\item \textbf{Specialized Language:} Since Xtend is a language that is specialized for the task of code generation, it contains many features that are useful for the process of transforming a source language into a target language. 

One of these features is `rich strings' which allow the user to specify templates in which custom code can be inserted. Rich string also allow IF-THEN-ELSE constructs and FOR loops to be included inside the string. One of the key features of rich strings is smart handling of white spaces in the generated output. White spaces are not written into the output as is but preprocessed. This allows for readable templates, as well as nicely formatted output.
\item \textbf{On-the-fly Code Generation:} Once the Eclipse instance with the integrated plugin is launched and a user starts creating models in our DSL, the code generator automatically starts to generate code. As soon as the user saves the DSL file, the corresponding code is generated if there are no errors in the DSL file. Xtext keeps the AST of the textual models in memory, and the AST is modified during execution as the user adds and removes models. The code generation process operates on this AST every time the file is saved. This was beneficial in our case as we did not need to explicitly invoke any `compile' command to generate the code. However, there may be cases when this behaviour might not be desired; for example, if the DSL file (and hence the corresponding AST) is very large. It would require a large amount of resources to continuously operate on this AST to generate code.
\end{enumerate}

\textbf{Problems Faced:} We also encountered some problems during the process of implementing the code generator. Some of these include:

\begin{enumerate}
\item \textbf{Learning Xtend:} As the code generator has to be written in Xtend, the user is required to learn a completely new `programming language'. Xtend is meant to be a general purpose language tailored for code generation. However, as it resembles Java it can get confusing for the user as it differs from Java in certain key aspects. For example, data types are inferred at runtime rather than explicitly declared.
\item \textbf{Embedding Code in Rich Strings: } In order to embed code into rich strings, the function call must be enclosed in guillemets. Initially, we mistook the guillemets for $<<$ and $>>$ characters. This led to confusion about why our code wasn't working as intended. Even after we figured out that guillemets were used, we didn't know how to type them in Eclipse. For a while, we simply copy/pasted the guillemets from the source code in the tutorial. Later on, we found out from a forum post that they can be typed by pressing \textit{Ctrl + Shift + <}. It would have been much easier to use some other characters instead of guillemets for this purpose. They cannot even be typed in LaTeX without including the French or German language package.
\item \textbf{Limited Documentation:} There was limited documentation on how to write a code generator. In the official documentation, there was only one simple tutorial which did not cover all the aspects of code generation (such as how to parse complex expressions).
\item \textbf{EMF Models:} The AST that is used to generate the code is in the form of EMF \textit{Ecore} models. Therefore, we had to learn about EMF in order to understand how to traverse the AST correctly. The Xtext and Xtend documentation did not contain anything helpful in this regard.
\item \textbf{Parsing Conditions and Expressions:} It was very hard to parse boolean conditions and mathematical expressions from the AST, as it required that we recursively traverse the AST to re-construct the expressions from the syntax tree. It took us some time to understand how to correctly traverse the AST. It would have been easier if there was some method to flatten the AST at a particular node and perform some pattern matching operation.

\end{enumerate}

\subsection{Framework Development}

While creating the user interface was quite straightforward, connecting the generated code to the framework was not so clear. 
As we described in section~\ref{sec:framework}, we went through several possible ways of doing it. 
Although we chose and used reflection in our project, we have some concerns about it. 
The main one is that not all programming languages have a technology similar to reflection in Java. 
For instance, if the target programming language was C or C++, we would not be able to use this approach. 
Another concern is that the operation that is performed using reflection requires more system resources than a direct implementation. 
Thus, we think that our approach might have some limitations even when the target language supports reflection.

As a possible solution, we think about using some combination of inheritance and reflection. 
It is likely to be possible to split the complexity of implementation between the code generator and the framework, and thus prevent both of them having difficulties with maintenance. 
After that, we may try to use reflection only during initialization block, which will be executed only once at the start of the program; doing that we might address the performance issue. 
Nevertheless, additional study is needed to find an elegant solution that will not use reflection at all.
